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PPP Vendor Extensions 


Status of this Memo 


This document provides information for the Internet community. It 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Abstract 


The Point-to-Point Protocol (PPP) [1] provides a standard method for 
transporting multi-protocol datagrams over point-to-point links. PPP 
defines an extensible Link Control Protocol (LCP) for establishing, 
configuring, and testing the data-link connection; and a family of 
Network Control Protocols (NCPs) for establishing and configuring 
different network-layer protocols. 


This document defines a general mechanism for proprietary vendor 


extensions. 
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Lis 


Control Packets 


The Packet format and basic facilities are already defined for LCP 
[1] and related NCPs. 


Up-to-date values of the LCP Code field are specified in the most 
recent "Assigned Numbers" [2]. This document concerns the following 
values: 


0 Vendor Specific 


1.1. Vendor Specific Packet 
Description 


Some implementors might not need nor want to publish their 
proprietary algorithms and attributes. This mechanism is 
available to specify these without encumbering the IANA with 
proprietary number requests. 


Vendor Specific packets MAY be sent at any time, including before 
LCP has reached the Opened state. 


The sender transmits a LCP or NCP packet with the Code field set 
to 0 (Vendor Specific), the Identifier field set, the local 
Magic-Number (if any) inserted, the OUI and Kind fields set, and 
the Value(s) field filled with any desired data, but not exceeding 
the default MRU minus twelve. 


Receipt of a Vendor Specific packet causes the RXR or RUC event. 
The response to the Vendor Specific packet is vender specific. 


Receipt of a Code-Reject for the packet SHOULD generate the RXJ+ 
(permitted) event. 


Rationale: 
This is defined as general feature of all PPP Control Protocols, 
to avoid future conflicts in vendor secretly self-assigned Code 


numbers. 


A summary of the Vendor Specific packet format is shown below. The 
fields are transmitted from left to right. 
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HA A AAA A O toto AO A A A O O O O A A A o A A ++ 
| Code | Identifier | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
| Magic-Number | 
E toto ta tatatatititoto ta tatatatitititetetetatat 
| OUI Kind | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 
| Value (s) 

+-+-+-+-+-+-+-+-+ 


Code 
0 for Vendor Specific 
Identifier 


The Identifier field MUST be changed for each Vendor Specific 
packet sent. 


Length 
>= 12 
When the Length is twelve, no Value(s) field is present. 
Magic-Number 
The Magic-Number field is four octets and aids in detecting links 
that are in the looped-back condition. Until the Magic-Number 
Configuration Option has been successfully negotiated, the Magic- 
Number MUST be transmitted as zero. See the Magic-Number 
Configuration Option for further explanation. 
OUI 
three octets. The vendor's Organizationally Unique Identifier. 


The bits within the octet are in canonical order, and the most 
significant octet is transmitted first. 


Kind 
one octet. Indicates a sub-type for the OUI. There is no 
standardization for this field. Each OUI implements its own 
values. 


The Kind field may be extended by the vendor to include zero or 
more octets of the Value(s) field. 
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2a 


2. 


Value (s) 


Zero or more octets. The details are implementation specific. 


Configuration Options 


The Configuration Option format and basic options are already defined 
for LCP [1]. 


Up-to-date values of the LCP Option Type field are specified in the 
most recent "Assigned Numbers" [2]. This document concerns the 
following values: 


0 Vendor-Specific 


1. Vendor-Specific Option 
Description 


Some implementors might not need nor want to publish their 
proprietary algorithms and attributes. This mechanism is 
available to specify these without encumbering the IANA with 
proprietary number requests. 


Before accepting this option, the implementation must verify that 
the Organizationally Unique Identifier and Kind specify a known 
mechanism, and that any vendor specific negotiation values are 
fully understood. 


Rationale: 
This is defined as general feature of all PPP Control Protocols, 
to avoid future conflicts in vendor secretly self-assigned Type 


numbers. 


A summary of the Vendor-Specific Configuration Option format is shown 
below. The fields are transmitted from left to right. 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type | Length | OUI 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Kind | Value(s) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
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Type 


When the Length is six, no Value(s) field is present. 
OUI 


three octets. The vendor's Organizationally Unique Identifier. 
The bits within the octet are in canonical order, and the most 
significant octet is transmitted first. 


Kind 
one octet. Indicates a sub-type for the OUI. There is no 
standardization for this field. Each OUI implements its own 
values. 


The Kind field may be extended by the vendor to include zero or 
more octets of the Value(s) field. 


Value (s) 
Zero or more octets. The details are implementation specific. 
3. Organizationally Unique Identifiers 


The three-octet Organizationally Unique Identifier (OUI) identifies 
an organization that administers the meaning of the message. This 
OUI is based on IEEE 802 vendor assignments. 


IEEE contact details for assignment of an OUI are given in [RFC- 
1700]. Vendors that desire to use their IEEE 802 OUI for PPP Vendor 
Extensions should also register the OUI with IANA. 


In the alternative, a vendor that does not otherwise need an IEEE 
assigned OUI can request a PPP specific OUI from IANA. This OUI 
shall be assigned from the 'CF0000” series. This has both the 
"locally-assigned" and "broadcast/multicast" bits set to 1; that is, 
the least significant two bits of the most significant octet are both 
set to 1. 


Appearance in memory, bits transmitted right-to-left within octets, 
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octets transmitted left-to-right: 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|11100111 1I|SXXXXXXXXXXXXXXX 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Multicast 
Local 


Rationale: 


This is defined for vendors that are not able to use IEEE 


assignments, such as software-only vendors. 


May 1997 


It is not clear how the IEEE assigns blocks. In some instances, 


the "locally-assigned" bit is known to have been used. 


However, multicast has no meaning in PPP. Therefore, an IEEE 


assigned OUI would have the multicast bit cleared to 0. 


The 'CF0000” series was arbitrarily chosen to match the PPP NLPID 


"CF, as a matter of mnemonic convenience. 


Security Considerations 


Security issues are not discussed in this document. 
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Contacts 


Comments about this document should be discussed on the ietf- 
ppp@merit.edu mailing list. 


This document was reviewed by the Point-to-Point Protocol Working 
Group of the Internet Engineering Task Force (IETF). The working 
group can be contacted via the current chair: 


Karl Fox 

Ascend Communications 

655 Metro Place South, Suite 379 
Dublin, Ohio 43017 


karl@Ascend.com 


Questions about this document can also be directed to: 


William Allen Simpson 

DayDreamer 

Computer Systems Consulting Services 
1384 Fontaine 

Madison Heights, Michigan 48071 


wsimpson@UMich.edu 
wsimpson@GreenDragon.com (preferred) 
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